Performance monitoring system, method and apparatus

ABSTRACT

A computer in a networked computer system is programmed to perform a performance monitoring method for an invoicing process, the invoicing process generating an invoice occupying one or more of a plurality of discrete states at any one time. The method includes the steps of defining performance criteria for at least part of the invoicing process, recording information relating to the invoice that may affect the performance criteria and analysing at least some of the recorded information to generate a performance report for at least part of the invoicing process, the performance report comparing a performance of at least part of the invoicing process against the performance criteria to provide an indication of the efficiency of at least part of the invoicing process.

FIELD OF THE INVENTION

The invention relates to a performance monitoring system, method andapparatus. In particular, although not exclusively, the inventionrelates to a system, method and apparatus that monitor users'performance in dealing with the entire lifecycle of invoices includingpreparation, output, dispute handling, negotiation and payment ofinvoices.

BACKGROUND TO THE INVENTION

Conventionally, once goods and/or services or the like have beenprovided by a supplier to a consumer, the consumer is invoiced for thegoods and/or services and the invoice is to be paid within a specifiedtime period.

In the economy there is an emerging difference in corporate behaviour inhandling invoices related to tangible goods versus those related tointangibles such as services. Large corporations have very sophisticatedprocedures and computer systems to deal with the purchase of tangiblegoods. Purchase orders are issued, goods are delivered, clerks checkgoods received against the order and if everything matches then paymentis made. Organisations with large and consistent purchasing arrangementssuch as retailers are so well organised they can achieve payment cyclesas low as seven days and even derive early payment discounts from thevendors. In comparison, handling the acquisition and payment ofintangible goods is much more difficult and variable. This results inmuch longer payment times for providers of intangible goods andservices.

One reason for the difference in behaviour is because receipt of theintangible goods and services is a matter of opinion not fact. Physicalgoods can be counted, quality measured, and location determined, whichis not always possible with intangible goods. Another reason is becausethe receipt of intangible goods and services is often handled directlyby a user who may be employed in any position within the buyingorganisation and the buying organisation usually does not have thesophisticated processes to support these users/buyers in the same waythat the dedicated receiver clerk is supported by the corporatecomputing infrastructure.

That the receipt of goods is based on opinion means that there may beuncertainty about the final value of an invoice that is mutuallyacceptable to both the supplier and buyer. In other words the invoiceitself becomes a negotiation, which adds considerably to the timebetween provision of the goods/services and payment and to thetransaction costs involved.

The lack of dedicated receiver support systems and training means thatthe user/buyer often does not fully understand how their own procurementsystems operate and the exact formalities with which an invoice mustconform. This may result in inaccuracies in the details of the invoice,which necessitates cancellation of the original invoice, sometimes viathe creation of credit notes, and the issuance of a replacement invoicecomprising amended details. Not only is this inefficient, but paymentwill be delayed and there may be further disagreement between thesupplier and the consumer regarding payment due dates. Furthermore,whilst invoices are being amended following the identification of adiscrepancy, the reason(s) for delays in payment are often not apparent.

The aforementioned payment problem has been well recognised and specificparts of the invoice life cycle have been addressed to a certain extentby automated document management systems and methods with which theprior art base is replete. For example, there are many systems andmethods concerned with the generation, distribution and payment ofinvoices including the issuance of reminders when invoices are overduefor payment.

One such electronic billing system, which replaces the preparation andmailing of paper statements with electronic statement presentment, isdisclosed in U.S. Pat. No. 5,963,925 assigned to Visa InternationalService Association. Although this system facilitates the electronicpayment of invoices by multiple customers of multiple billersirrespective of the customers' financial institution and minimises therelationships needing to be established between billers and serviceproviders, this system does not provide means for modifying aspects ofthe invoice in the event of a dispute between the biller and thecustomer. Many other systems permit multiple modifications of invoicesby suppliers prior to issuance, but do not permit modification once theinvoice has been issued.

One system that offers a degree of invoice construction flexibility isdisclosed in U.S. Pat. No. 6,282,552 assigned to Daleen Technologies,Inc. This system allows the sender of an electronic invoice to specifyportions of the invoice that are changeable by one or more recipients ofthe invoice and tracks the changes to the invoice data made by therecipients.

Another system and method for electronic invoice presentment isdisclosed in US Patent Application No. 2002/0184123 assigned to SunMicrosystems, Inc. This system and method includes an electronic invoicedispute resolution process that is invoked when line items of an invoiceare rejected by a designated approver associated with a purchasingentity. A provider resolution process is invoked to enable the providerof the goods/services to dispute or approve the disputed line items andthe results of this provider resolution process are made available tothe purchasing entity.

Other responses to the aforementioned problems can be seen in the widearray of payment systems that are available, from traditional cash andcheque payments to more modern approaches such as third party credit,electronic funds transfer, and payment hubs.

Some industries have tried to address the issue of payment negotiationby initially recognising this fact and developing specific practices toaddress these issues. An example of such an industry is the Australianconstruction industry. The practice of many of the large projectmanagement firms is to have monthly reviews of progress withsub-contractors and to negotiate a progress payment. The constructionfirms then have special dispensation from the Australian Tax Office togenerate invoices on behalf of the subcontract vendors.

All of these approaches illustrate that endeavours to achieve efficientpayment are widespread and clearly highly desirable. Additionally, theresponse required varies from industry to industry and from firm tofirm. With so many responses and tools being available, the issue thenbecomes which is the right one for any given vendor to use and in whichcircumstance. Although some systems and methods allow invoices to bedisputed, negotiated and amended prior to being finalised they do notidentify inefficiencies in the invoice generation, finalisation andsettlement procedure.

Hence, there is a need for a system, method and/or apparatus thataddresses or at least ameliorates one or more of the aforementionedproblems and/or provides a useful commercial alternative. Preferably,such a system, method and/or apparatus should identify inefficiencies inthe invoice process.

In this specification, the terms “comprises”, “comprising”, “includes”or “including” or similar terms are intended to mean a non-exclusiveinclusion, such that a method, system and/or apparatus that comprises alist of elements and/or steps does not include those elements and/orsteps solely, but may well include other elements and/or steps notlisted.

SUMMARY OF THE INVENTION

According to one aspect, although it need not be the only or indeed thebroadest aspect, the invention resides in a performance monitoringmethod for an invoicing process, said invoicing process generating aninvoice occupying one or more of a plurality of discrete states at anyone time during said invoicing process, said method including the stepsof:

a) defining performance criteria for at least part of said invoicingprocess;

b) recording information relating to the invoice that may affect saidperformance criteria; and

c) analysing at least some of said recorded information to generate aperformance report for at least part of the invoicing process, saidperformance report comparing a performance of at least part of theinvoicing process against said performance criteria to provide anindication of the efficiency of at least part of said invoicing process.

Preferably, the step of defining the performance criteria includesperforming step b) and step c) for an initial period.

Preferably, the step of recording information includes recording one ormore of the following: a duration for which the invoice occupies one ormore of said discrete states, a before state and an after state of theinvoice for a transition between said discrete states, an action thattriggers a transition between said discrete states, an identity of auser or system element which performs said action that triggers atransition between said discrete states, a communication prior to anaction that triggers a transition between said discrete states,information which impacts on the action that triggers a transitionbetween said discrete states, a medium through which said invoice ispublished, a number of times an invoice occupies a discrete state, acost associated with each action relating to the invoice.

The step of recording a duration for which the invoice occupies eachsaid discrete state may include recording a time and date of atransition between said discrete states.

Suitably, the invoicing process comprises nine discrete states, whichmay include the states: under construction, awaiting approval, publishlegal, publish draft, accept legal, queried, edit, cancelled, closed.

Suitably, the number of discrete states in the invoicing process maychange over time.

Preferably, the method further includes the step of defining actionsthat trigger transitions between the discrete invoice states.

Preferably, the method further includes the step of defining conditionsthat must be satisfied to permit specific transitions between discreteinvoice states to occur.

Suitably, the method further includes the step of restricting the userswho are permitted to initiate state transitions.

Suitably, the method further includes the step of restrictinginformation relating to the invoice that may be viewed or changed by auser.

Preferably, the method further includes the step of defining one or moreassociations between the actions that trigger transitions and thetransitions to enable the cause of a transition to be determined.

Preferably, the method further includes the step of defining conditionsthat must be satisfied to permit specific transitions between discreteinvoice states to occur.

Preferably, the method further includes the step of defining one or moreassociations between actions that may be performed on invoices and thediscrete invoice states to specify invoice actions that are permittedfor the invoice in each respective state.

The method may further include recording at least some of theinformation relating the invoice for a time period before and a timeperiod after a change is introduced to the invoicing process todetermine the effect of the change.

According to another aspect, the invention resides in a performancemonitoring system for an invoicing process, said invoicing processgenerating an invoice occupying one or more of a plurality of discretestates at any one time during said invoicing process, said systemcomprising:

a supplier machine for a supplier of the goods and/or services to whichthe invoice relates;

a buyer machine for a buyer of the goods and/or services to which theinvoice relates;

an administrator machine coupled to be in communication with saidsupplier machine and said buyer machine via a communications network,said administrator machine performing the steps of:

-   -   a) defining performance criteria for at least part of said        invoicing process;    -   b) recording information relating to the invoice that may affect        said performance criteria; and    -   c) analysing at least some of said recorded information to        generate a performance report for at least part of the invoicing        process, said performance report comparing a performance of at        least part of the invoicing process against said performance        criteria to provide an indication of the efficiency of at least        part of said invoicing process.

Preferably, the system further comprises a data store in communicationwith the administrator machine for storing one or more associationsbetween the actions that trigger transitions and the transition toenable the determination of the cause of a transition.

Preferably, the data store also stores one or more associations betweenactions that may be performed on the invoices and the discrete invoicestates to specify invoice actions that are permitted for the invoice ineach respective state.

Preferably, the system further comprises a third party machine coupledto be in communication with said supplier machine, said buyer machineand/or said administrator machine via said communications network forsending and/or receiving information relating to the invoice that mayaffect said performance criteria.

According to a further aspect, the invention resides in a computer in anetworked computer environment, said computer programmed to perform aperformance monitoring method for an invoicing process, said invoicingprocess generating an invoice occupying one or more of a plurality ofdiscrete states at any one time during said invoicing process, saidmethod including the steps of:

a) defining performance criteria for at least part of said invoicingprocess;

b) recording information relating to the invoice that may affect saidperformance criteria; and

c) analysing at least some of said recorded information to generate aperformance report for at least part of the invoicing process, saidperformance report comparing a performance of at least part of theinvoicing process against said performance criteria to provide anindication of the efficiency of at least part of said invoicing process.

Further features of the present invention will become apparent from thefollowing description.

BRIEF DESCRIPTION OF THE DRAWINGS

To assist in understanding the invention and to enable a person skilledin the art to put the invention into practical effect preferredembodiments of the invention will be described by way of example onlywith reference to the accompanying drawings, wherein:

FIG. 1 is a schematic representation of the system of the presentinvention;

FIG. 2 is a high level workflow diagram showing the main events in thelifecycle of an invoice;

FIG. 3 shows an example of a matrix which defines valid statetransitions within the invoice cycle according to one embodiment of thepresent invention;

FIG. 4 is a diagram showing an example of permissible state transitions;

FIG. 5 shows an example of an invoice audit history log;

FIG. 6 shows an example of a basic analysis report generated by thepresent invention;

FIG. 7 illustrates the association between invoice states, invoiceactions, users and conditions;

FIG. 8 illustrates the association between invoice actions, transitionsbetween invoice states, users and conditions;

FIG. 9 is a flow chart illustrating the determination of whether actionswithin an invoice state are permitted;

FIG. 10 is a flow chart illustrating the determination of whethertransitions between invoice states are permitted;

FIG. 10A is a flow chart showing method steps of the performancemonitoring method;

FIG. 11 is a screenshot of an audit history for an invoice;

FIGS. 12A-12C show examples of performance reports comparing performanceof a vendor company with that of an employee of the vendor company;

FIGS. 13A-13C show examples of performance reports comparing performanceof a vendor company with that of a customer of the vendor company; and

FIG. 14 shows an example of a performance report for the overalllifecycle of the invoice for different invoice publishing methods.

DETAILED DESCRIPTION OF THE INVENTION

The system, method and apparatus of the present invention pertain to theconstruction, delivery, follow-up, negotiation, payment and otheractions associated with invoices, monitoring how and when these eventsoccur and analyzing this recorded information to generate performancereports indicative of the efficiency or otherwise of the invoiceprocess.

The present invention may be employed, for example, in the environmentshown schematically in FIG. 1, which shows the system 1 of the presentinvention. The system comprises a supplier machine 2 of a supplier orvendor of goods and/or services or the like, a buyer machine 4 of abuyer of the goods and/or services provided by the vendor/supplier andan administrator machine 6.

Machines 2, 4, 6 are coupled to communications network 8, such as anintranet, LAN, WAN or global communications network such as theInternet.

In the example shown in FIG. 1, machines 2, 4 are in the form ofconventional computer terminals and administrator machine 6 is in theform of an application server or mail server. However, it is alsoenvisaged that supplier, buyer and/or administrator machines 2, 4, 6could be mobile communication devices, such as hand-held PCs, suitablyenabled mobile phones or personal digital assistants (PDAs) or the like.In such cases, communication network 8 will be or will include atelecommunications network.

Third parties 9 such as financial institutions and payment hubs may alsointeract with the machines 2, 4, 6 via the communications network 8 andare therefore also coupled to be in communication with machines 2, 4, 6via the communications network 8, as shown in FIG. 1.

It will be appreciated that invoices, amendments thereto and agreementsthereon and other communications relating to invoices may becommunicated between a supplier, a buyer and administrator usingconventional communication means such as mail and/or electronic meanssuch as telephone, facsimile, the World Wide Web, email, SMS, EDI and/orother communication means.

In the embodiment shown in FIG. 1, the administrator machine 6 may be anapplication service provider (ASP) comprising one or more applicationsand a data store 6 a such as a database for the provision of theinvention to suppliers 2, buyers 4 and third parties 9. In such anembodiment, each of the suppliers 2, buyers 4 and third parties 9 mayhave their own dedicated information systems, 2 a, 4 a and 9 arespectively, such as their accounting systems, which may store theirgeneral ledger (GL) as referred to later herein, their enterpriseresource planning (ERP) systems, practice management systems and thelike.

In alternative embodiments, some or all of the functions of theadministrator terminal 6 are part of the supplier's system and/or thebuyer's system and/or the system of the third party 9. In suchembodiments, notifications of actions relating to the invoice andqueries etc. are still transmitted over the communications network 8 orvia the alternative communication means described above. Thisdemonstrates that the workflow can exist across the supplier, buyer,third party and/or administrator.

A high-level workflow diagram showing the main events in the life of aninvoice is shown in FIG. 2. A user in the vendor organization signs in10, and sets up 12 an invoice for a particular recipient according tothe goods and/or services supplied. The invoice includes informationthat would conventionally appear in invoices, such as the type ofgoods/services supplied, the quantity provided, the cost per unit, totalcost, the date supplied, tax, account number etc. The invoice is thenpublished 14 and the buyer can indicate acceptance 16 of the debt owedin relation to the invoice prior to payment. The final stage in thisexample is payment 18 of the invoice.

As represented by blocks 20 and 22 and the dotted arrows in FIG. 2, theinvoice may be negotiated and agreed upon by the supplier and/or thebuyer before being accepted in step 16. For example, prior topublication, in step 20 the supplier may amend the invoice after set upand provide their approval prior to publication. Additionally, oralternatively, after publication, in step 22 the buyer may negotiate theinvoice, which may necessitate amendments being made to the invoice bythe user of the vendor organization and re-publication of the amendedinvoice. Once the contents of the invoice have been finalized into alegally binding state, the invoice will be entered in a general ledger(GL), which will render the relevant taxes payable.

However, it will be appreciated that other events can exist in the lifeof an invoice other than those shown in FIG. 2 and these are describedhereinafter.

Placing an invoice publishing system within the environment described inFIG. 1, in which at least some of the supplier's, buyers' and/or thirdparties' activities relating to the invoice can be captured, creates theopportunity to monitor not only the stages an invoice goes throughwithin the vendor organization, but also the opportunity to obtainimportant and useful data on certain stages of processing the invoicewithin the buyer and/or third party organization.

In one embodiment, the monitoring system, method and apparatus of thepresent invention recognize nine discrete states through which aninvoice may pass during the lifecycle of the invoice. These states orphases are listed in Table 1 below: TABLE 1 Invoice State DescriptionUnder “Under Construction” commences from the time that the vendorpolicy Construction and procedures state that an invoice should beissued. This can be at a nominated regular period such as at the startof the month or at specified milestones. During the construction phasethe invoice components are assembled into a form ready for presentation.Construction can be automated or it can be a manual process carried outby a person authorised by the vendor. Awaiting The “Awaiting Approval”state allows for inspection and verification of an Approval invoice by aperson authorised by the vendor. Generally there is a separation ofduties between persons authorised to handle construction verses thosegiven approval responsibility. Publish The “Publish Legal” state is whenthe vendor has issued an invoice to Legal the buyer that conforms fullyto the format prescribed within the jurisdiction it is being issued.Publish Draft The “Publish Draft” state denotes when a preview of thefinal invoice is issued to the buyer. Generally this is done as a meansto engage in negotiations about the final form of the invoice withoutplacing it into a legal form. Accept Legal The invoice enters the“Accept Legal” state when the buyer has accepted the invoice in itsfinal form but as yet has not paid the amount due. Queried The invoiceenters the “Queried” state when the buyer raises some issue regardingthe invoice. This may be an outright rejection that any debt exists, orgeneral issues such as the amount, the content or a simple request forclarification. Edit This state is entered when changes to the invoiceare to be made. This may include changes to the content or additionssuch as background information, or credit notes. Cancel The vendor cancancel an invoice and this ends the invoice process. Close An invoice is“Closed” when then entire transaction is complete. This occurs when theinvoice amount equals the payments received plus credits and write offs.

Invoice cycles begin with the invoice being “under Construction” and endwith a state of either “Cancel” or “Close”. The various states recognizethat in some instances draft invoices are used as a means of negotiationof a final amount. They also recognize that an invoice may have to gothrough a number of revisions or additions before the final transactionis concluded.

Although “Under Construction” is shown as the initial invoice state, aprecursor state of “Invoice Start” or the like is often required inparticular industries or companies wherein an invoice is issued atspecified times, such as the start of each month, or at prescribedmilestones. Other states may be required as dictated by, for example,the particular application or the jurisdiction. For example, in certaincountries, invoices require a government stamp of approval, whichnecessitates at least one additional state. Hence, the invention is notlimited to the nine states identified in the embodiment referred toabove.

The invoice states in themselves do not imply a rigidly defined workflowor path that an invoice must take during its lifecycle. It will beappreciated that workflows can vary based on the work and accountingpractices of the vendor and/or the buyer and/or the third party. It isenvisaged that workflows and the number of discrete states in theinvoice lifecycle may change over time to accommodate changing workpractices. Furthermore, the workflow can exist across all partiesinvolved in the invoicing process.

The possible paths can be constrained by specifying valid transitionsbetween invoice states. This is shown in FIG. 3. FIG. 3 is an example ofa matrix of valid state changes or transitions for an organization thatis issuing both draft and legal invoices, where the buyer has theability to approve or query an invoice. A valid state transition tablecan be described in a valid state transition diagram such as that shownin FIG. 4. The numbered valid transitions between invoice states shownin FIG. 4 correspond to the TRUE matrix entries shown in FIG. 3. Hence,an invoice that is in the state of, for example, “under construction”may validly move to a state of “awaiting approval” (transition 1) or toa state of “cancel” (transition 14), but not to a state of “publishlegal”.

In many cases, the invoice will only occupy a single discrete state atany one time. However, it is envisaged that an invoice maysimultaneously occupy more than one state. For example, part of aninvoice may be in the state of awaiting approval and another part of thesame invoice may be in the edit state. Another example could be wherethe invoice is awaiting buyer approval and simultaneously awaitinggovernmental approval. Such an example would require multiple approvalstates in parallel.

An example of the actions within a software application that triggereach state transition shown in FIGS. 3 and 4 are specified in Table 2below: TABLE 2 State Transition Trigger Action 1 Click “Ready toPublish” button 2 Click “Publish Legal” button 3 Click “Paid” or “Writeoff” button and entering outstanding amount exactly 4 Click “Edit”button 5 Click “Ready to Publish” button 6 Click “Query” button 7 Click“Accept” button 8 Click “Paid” or “Write off” button and enteringoutstanding amount exactly 9 Click “Query” button 10 Click “Edit” button11 Click “Publish Draft” button 12 Click “Accept” button 13 Click“Query” button 14 Click “Cancel Invoice” 15 Click “Cancel Invoice” 16Click “Cancel Invoice”

The vendor organization can then define the workflow and companyprocedures by;

-   -   1. Specifying the actions which trigger each state change        (illustrated in Table 2);    -   2. Restricting the users who may make a specific state change;    -   3. Defining prerequisites/conditions that allow a specific state        change to occur;    -   4. Restricting the invoice or invoice related data which each        user may view or change; and    -   5. Defining any prerequisites/conditions that enable users to        make the changes.

An example of a prerequisite or condition for allowing a statetransition to occur is that a user may not be allowed to move an invoiceinto a “Publish Draft” state if it has previously been through either a“Publish Legal” or “Accept Legal” state. An example of a prerequisite orcondition for allowing specific aspects of the invoice to be modifiedwithin a state is that the invoice is in the “Edit” state. The user mayonly add notes to the buyer or credit notes of the invoice, but may notbe able to change the specific content of the invoice if it has beenthrough either a “Publish Legal” or “Accept Legal” state. However, theuser may change the content of the invoice if it has never been througha “Publish Legal” or “Accept Legal” state, but may not add credit notes.It will be appreciated that further prerequisites or conditions may bespecified that restrict the occurrence of state transitions.

With reference to FIG. 7, each state in the workflow has a number ofassociated invoice actions, which identify the actions permitted for aparticular invoice state. Invoice actions are specified in InvoiceActiontable 24. This table and other tables and data referred to herein arepreferably stored in a conventional data store associated and incommunication with administrator machine 6, as familiar to one skilledin the art. The invoice actions permitted when an invoice is in eachrespective state are specified in State_InvoiceAction table 26. A numberof roles and conditions are connected to each permitted state-actionassociation, which are specified in State_InvoiceAction_Role table 28.Table 28 specifies either a UserRole or a UserInvoiceRole. Examples ofUserRoles are supplier, buyer etc. Examples of UserInvoiceRoles areInvoiceOwner, InvoiceContact, InvoiceController etc. Table 28 alsospecifies one or more conditions or prerequisites associated with theinvoice and/or action and a State_InvoiceActionId. TheState_InvoiceActionId identifies the particular state-action associationspecified in State_InvoiceAction table 26. This arrangement enablesrules to be specified such as “The invoice Owner (UserInvoiceRole) canQuery (Action) the Invoice if it is in state Accept Legal (State) and itis non-web (Condition)” or A Controller (UserRole) can Edit (Action) anyinvoice (No Condition) when it is under Construction (State)”. Table 28identifies who is allowed to do the specific actions that are permittedin the various discrete states and the associated conditions.

With reference to FIG. 8, the actions associated with particular invoicestates are also associated with transitions between two states in theworkflow. Invoice actions are specified in InvoiceAction table 24.Invoice transitions from one state (a before state or prior state) toanother state (an after state) are specified in StateTrans table 30. Thepermitted invoice actions causing each permitted transition for eachrespective state are specified in StateTrans_InvoiceAction table 32 inthe form of transition-action associations. This enables theidentification of the action that triggers a transition. Each state willalso have a transition to itself, since some actions don't trigger achange of state. Such actions may be associated with self-transitions. Anumber of roles and conditions or prerequisites are connected to eachtransition-action association, which are specified in theStateTrans_InvoiceAction_Role table 34. Table 34 specifies either aUserRole or UserInvoiceRole as described above for table 28 in FIG. 7.Table 34 also specifies one or more conditions associated with theinvoice and/or action and a StateTrans_InvoiceActionid. TheStateTrans_InvoiceActionId identifies the particular transition-actionassociation specified in StateTrans_InvoiceAction table 32.

The method by which the present invention determines whether actions arepermitted in particular states will now be described with reference toFIG. 9. In step 100, the UserInvoiceRole is identified from the User andthe InvoiceId. In step 102, the rules stored in theState_InvoiceAction_Role table 28 are established based on the invoicestate and the InvoiceAction. The rules for the particular UserRole of agiven user in the absence of any conditions are checked, as representedby step 104. If valid, the action is allowed, step 106. If invalid, therules for the particular UserRole of a given user with conditions arechecked, as represented by step 108. If permitted, a check is made todetermine whether the one or more conditions are satisfied, step 110. Ifso, the action is allowed, step 106. If the one or more conditions arenot satisfied or the rules for UserRole of a given user are notpermitted, the rules for InvoiceRole of a given user without conditionsare checked, step 112. If permitted, the action is allowed, step 106. Ifnot, the rules for InvoiceRole of a given user with conditions arechecked, step 114. If invalid, the action is not allowed, step 118. Ifvalid, a check is made to determine whether the one or more conditionsare satisfied, step 116. If the condition(s) is/are satisfied, step 116,the action is allowed, step 106. If the condition(s) is/are not met, theaction is not allowed, step 118.

The method by which the present invention determines whether transitionsfrom one state to another state are permitted will now be described withreference to FIG. 10. In step 120, the state into which it is proposedthe invoice will move is determined from the InvoiceAction stored intable 24 and the fromstate (before state of the invoice) stored in table30. In step 122, the UserInvoiceRole is identified from the User and theInvoiceId. The UserRoles for the Transition and the Action aredetermined from the intoState (after state of the invoice) and thefromState stored in table 30 and the InvoiceAction, as represented bystep 124. The result is the data stored in theStateTrans_InvoiceAction_Role table 34.

The rules for the particular UserRole of a given user in the absence ofany conditions are checked, as represented by step 126. If valid, thetransition and therefore the action, is allowed, step 128. If invalid,the rules for the particular UserRole of a given user with conditionsare checked, as represented by step 130. If permitted, a check is madeto determine whether the one or more conditions are satisfied, step 132.If so, the transition is allowed, step 128. If the one or moreconditions are not satisfied or the rules for UserRole of a given userare not permitted, the rules for InvoiceRole of a given user withoutconditions are checked, step 134. If permitted, the transition isallowed, step 128. If not, the rules for InvoiceRole of a given userwith conditions are checked, step 136. If invalid, the transition is notallowed, step 140. If valid, a check is made to determine whether one ormore condition(s) is/are satisfied, step 138. If so, the transition isallowed, step 128. If the condition(s) is/are not met, the transition isnot allowed, step 140.

With reference to FIG. 10A, once the system and apparatus has beenconfigured for one or more specific workflows, performance criteria aredefined for at least part of the invoicing process, as represented bystep 150, against which the performance of the invoicing process iscompared. Performance monitoring then occurs by recording theinformation relating to the invoice that may affect the performancecriteria, as represented by step 152.

The recorded information may include the time of each state transition,the action and/or trigger which caused the transition, which user orsystem caused the state transition, the total value of the invoice,credit notes, write-offs, and payments. Other information may also berecorded such as notifications, e.g. communications impacting on theaction/trigger event, specifics of the changes made such as reasons forwrite ups, write downs, discounts and the like, the number of times aninvoice occupies or makes a transition through the discrete invoicestates, changes to customer details and other such information. Hence, acomplete transaction log of all changes and events that occur in thesystem that impact on the invoice in some way is created. An example ofsuch a log for an invoice is shown in FIG. 5.

With further reference to FIG. 10A and steps 154 and 156, at least someof the recorded information is then analysed to generate one or moreperformance reports for at least part of the invoicing process,depending on which aspects of the invoicing process is being analysed.The performance reports compare the performance of the invoicing processagainst the performance criteria, thus providing an indication of theefficiency of the invoicing process or part thereof. Examples of suchperformance reports are shown in FIGS. 12A-14 and discussed in moredetail later. As shown in FIG. 10A, definition of the performancecriteria may include recording the invoice related information andanalysing it for an initial period to obtain meaningful performancecriteria.

Another example of an audit history of an invoice is shown in thescreenshot of FIG. 11. FIG. 11 shows the date of the logged event, theentity causing or effecting the event, which could be a user or a systemelement automatically effecting an event. FIG. 11 also shows the type ofevent. This may be a notification, such as a reminder to pay an unpaidinvoice that is automatically generated by a system element, or changein invoice state. A state of the invoice prior to and after the loggedevent is also shown. The audit history of FIG. 11 also shows the methodor type of notification, such as email, fax, verbal (such as telephonecall) and the reason for the event, such as inactivity or a change instate of the invoice.

In one embodiment, the performance monitoring and analysis of theinvention is achieved by recording the times and actions triggering thestate transitions. The log of transition times and dates can then beconverted into duration within a state and this information creates thebasic performance analysis tool for determining the efficiency of thesystem and users of the system. The time within a state can then bereported in numerous ways. The most basic report would be the averagetime in each state for an accounting period, which is illustrated inFIG. 6. From such analysis inefficiencies in the invoice process can beidentified and addressed.

Further examples of the results of performance analysis are shown inFIGS. 12A-C, FIGS. 13A-C and FIG. 14 in the form of performance reports.FIGS. 12A-C compare the performance of a vendor company or supplier withthe performance of an employee of that company. FIG. 12A shows theaverage time (in days) that invoices remain in a particular state overthe period of one year. FIG. 12B shows the number of invoices publishedby the different methods of over the Internet, via email, via facsimileand by mail, a total number of invoices and the average lifecycleduration. FIG. 12C shows the percentages of a total number of invoicesthat are published by mail, fax, email or over the Internet.

FIGS. 13A-C show the same types of performance reports as those in FIGS.12A-C, except that they compare the figures of customer A with those ofthe vendor company. This illustrates that the efficiency of both theissuer and payer of the invoice can be assessed.

FIG. 14 shows an example of a performance report for the overalllifecycle of the invoice for the different invoice publishing methods.This report shows the average time over the period of one year thatinvoices published by each method remain in each discrete invoice state.

In addition to the data that is recorded as described above and theaforementioned performance reports, other reports may be generated. Forexample, the cost associated with each action may be recorded in termsof, for example, employee time or an early payment discount and aperformance report generated accordingly. Performance reports thatillustrate the effect of a particular event may be produced such asreports generated before and after the introduction of an early paymentdiscount. The performance reports may be made available to suppliers 2,buyers 4 and or third parties 9 as required, e.g. via the communicationsnetwork 8 or via other communication means. Third parties 9 may alsosend and receive information relating to the invoice lifecycle via thecommunications network 8 or via other communication means. Suchinformation may include copies of the invoice, the effecting of triggerevents, such as making payments or changing a customer's status that mayimpact on the invoice.

Performance reports such as those described above identify and highlighttrends in the invoice lifecycle including both efficient and inefficientparts therein and enable suppliers, customers and financial institutionsto improve every aspect of their invoicing process.

Hence, the performance monitoring system, method and apparatus of thepresent invention addresses the problems of the prior art by recordingnot only the details of the invoice and changes thereto by the supplierand/or the buyer, but also by recording a range of other informationrelating to the invoice, such as a duration for which the invoiceoccupies one or more of said discrete states, a before state and anafter state of the invoice for one or more transitions between states,one or more actions that trigger the state transitions, an identity ofusers or system elements which perform the actions that triggertransitions, communications prior to an action that triggers statetransitions, information which impacts on the action that triggers statetransitions, a medium through which the invoice is published, a numberof times an invoice occupies a discrete state, and/or a cost associatedwith each action relating to the invoice.

This information is then analyzed to generate performance reports anddetermine the efficiency of the vendor's organisation as a whole,departments or employees of the vendor organisation, product lines,workflow, publishing method, customer groups and individual customers indealing with the invoice in any or all parts of the invoice lifecyclefrom creation to settlement.

Throughout the specification the aim has been to describe the inventionwithout limiting the invention to any one embodiment or specificcollection of features. Persons skilled in the relevant art may realizevariations from the specific embodiments that will nonetheless fallwithin the scope of the invention.

1. A performance monitoring method for an invoicing process, saidinvoicing process generating an invoice occupying one or more of aplurality of discrete states at any one time during said invoicingprocess, said method including the steps of: a) defining performancecriteria for at least part of said invoicing process; b) recordinginformation relating to the invoice that may affect said performancecriteria; and c) analysing at least some of said recorded information togenerate a performance report for at least part of the invoicingprocess, said performance report comparing a performance of at leastpart of the invoicing process against said performance criteria toprovide an indication of the efficiency of at least part of saidinvoicing process.
 2. The method of claim 1, wherein the step ofdefining the performance criteria includes performing step b) and stepc) for an initial period.
 3. The method of claim 1, wherein the step ofrecording information includes recording one or more of the following: aduration for which the invoice occupies one or more of said discretestates, a before state and an after state of the invoice for atransition between said discrete states, an action that triggers atransition between said discrete states, an identity of a user or systemelement which performs said action that triggers a transition betweensaid discrete states, a communication prior to an action that triggers atransition between said discrete states, information which impacts onthe action that triggers a transition between said discrete states, amedium through which said invoice is published, a number of times aninvoice occupies a discrete state, a cost associated with each actionrelating to the invoice.
 4. The method of claim 3, wherein the step ofrecording a duration for which the invoice occupies each said discretestate includes recording a time and date of a transition between saiddiscrete states.
 5. The method of claim 1, wherein the invoicing processcomprises nine discrete states.
 6. The method of claim 5, wherein thenine discrete states include the states: under construction, awaitingapproval, publish legal, publish draft, accept legal, queried, edit,cancel, close.
 7. The method of claim 1, wherein the number of discretestates in the invoicing process changes over time.
 8. The method ofclaim 1, further including the step of defining actions that triggertransitions between the discrete invoice states.
 9. The method of claim8, further including the step of defining one or more associationsbetween the actions that trigger transitions and the transitions toenable the cause of a transition to be determined.
 10. The method ofclaim 1, further including the step of defining conditions that must besatisfied to permit specific transitions between discrete invoice statesto occur.
 11. The method of claim 1, further including the step ofdefining one or more associations between actions that may be performedon invoices and the discrete invoice states to specify invoice actionsthat are permitted for the invoice in each respective state.
 12. Themethod of claim 1, further including the step of restricting the userswho are permitted to initiate state transitions.
 13. The method of claim1, further including the step of restricting information relating to theinvoice that may be viewed or changed by a user.
 14. The method of claim3, further including recording one or more of the parameters in claim 3for a time period before and a time period after a change is introducedto the invoicing process to determine the effect of the change.
 15. Aperformance monitoring system for an invoicing process, said invoicingprocess generating an invoice occupying one or more of a plurality ofdiscrete states at any one time during said invoicing process, saidsystem comprising: a supplier machine for a supplier of the goods and/orservices to which the invoice relates; a buyer machine for a buyer ofthe goods and/or services to which the invoice relates; an administratormachine coupled to be in communication with said supplier machine andsaid buyer machine via a communications network, said administratormachine performing the steps of: a) defining performance criteria for atleast part of said invoicing process; b) recording information relatingto the invoice that may affect said performance criteria; and c)analysing at least some of said recorded information to generate aperformance report for at least part of the invoicing process, saidperformance report comparing a performance of at least part of theinvoicing process against said performance criteria to provide anindication of the efficiency of at least part of said invoicing process.16. The system of claim 15, further comprising a data store incommunication with said administrator machine for storing one or moreassociations between the actions that trigger transitions and thetransition to enable the determination of the cause of a transition. 17.The system of claim 15, further comprising a data store in communicationwith said administrator machine for storing one or more associationsbetween actions that may be performed on invoices and the discreteinvoice states to specify invoice actions that are permitted for theinvoice in each respective state.
 18. The system of claim 15, furthercomprising a third party machine coupled to be in communication withsaid supplier machine, said buyer machine and/or said administratormachine via said communications network for sending and/or receivinginformation relating to the invoice that may affect said performancecriteria.
 19. A computer in a networked computer environment, saidcomputer programmed to perform a performance monitoring method for aninvoicing process, said invoicing process generating an invoiceoccupying one or more of a plurality of discrete states at any one timeduring said invoicing process, said method including the steps of: a)defining performance criteria for at least part of said invoicingprocess; b) recording information relating to the invoice that mayaffect said performance criteria; and c) analysing at least some of saidrecorded information to generate a performance report for at least partof the invoicing process, said performance report comparing aperformance of at least part of the invoicing process against saidperformance criteria to provide an indication of the efficiency of atleast part of said invoicing process.